This invention is primarily directed to the emulation of tape drive systems, their activity and data files as software objects, and is useful particularly to support legacy software that requires tape drive systems in their normal operation. The inventive concepts are particularly suitable for modern object oriented applications, and is well suited to use in Windows-based (operating systems of Microsoft Corporation) computing. The concepts defined by the embodiments described have wider application to the field of emulation of peripheral hardware systems generally, however.
A problem with computer systems over time is that legacy systems software is designed for the legacy system hardware and that hardware gets updated and replaced without a redesign of the legacy software. This creates a problem for the user who is using the computer for a number of tasks and cannot afford to have a rewrite of the legacy software accomplished, but needs new hardware for his other computing needs. A particular case in point is with Unisys Corporation""s 2200 series computer systems that used to have tape drives as the boot volume required for start-up of the-system. For a computer system user who needs to continue to use system or application software or both that require the 2200 computer, but who can no longer maintain such a system, a way to emulate the processor functions would enable him to run his 2200 legacy software on, for example a WINDOWS (Microsoft Corporation Operating System trade name) computer system, if the system also had a processor emulator for emulating the 2200 system. A way to do this is available in a software or hardware based 2200 processor emulator. However, as mentioned before, some of this software will rely on the existence of a magnetic tape drive system that was available with the legacy hardware, and rewriting old software is not the most productive use of coding resources.
(Processor emulation too is known, see for example U.S. Pat. No. 5,751,982, Morley, in which software emulation of a microprocessor is described. Too, emulation of processors via plug compatible emulation hardware is also known, as for example are seen in U.S. Pat. Nos. 5,497,456 and 5,727,217.) 
Accordingly there are substantial business needs or reasons to have tape drive peripheral emulators available in software.
A number of attempts have been made to emulate various features of tape drives and are described in the patent art. For perhaps the closest example, see U.S. Pat. No. 5,297,124 issued to Plotkin, et al. In this patent, a disk drive is made to emulate a tape drive in a xe2x80x9cplug compatiblexe2x80x9d fashion. Accordingly it requires a hardware interconnect device containing a processor, RAM, ROM, and supporting components to produce tape drive like responses for the host computer system addressing the Plotkin et al disk drive acting like a tape drive.
Earlier a patent issued to Kantner, U.S. Pat. No. 4,511,963, which described how to deal with the echo (verification) transmissions between the tape drive and the processor, among other things.
Brikner and Sankey in U.S. Pat. No. 4,727,512 described another interface system for allowing a computer system with a standard tape drive interface to communicate image data with such a computer, and Osterlund, in U.S. Pat. No. 4,775,969 described how to store and retrieve tape drive formatted data from an optical disk drive.
All these four patent references are incorporated herein hereby, in their respective entireties, for the disclosure they provide of the relevant features stated therein.
However, none of the art appears to have developed a tape drive emulator that was simply operating in software available to the computer system to be used by other software programs, legacy or otherwise, in the same computer system.
Unisys Corporation has developed simulators before too, but these were not developed as software objects, and therefore would require invocation of a processor simulator to enable a tape drive simulation. The tape drive simulators thus provided were not available for other uses, nor were they directly accessible by programs that did not go through the processor emulator to address them. Because of the tight coupling of the various parts of the emulation subsystems, the programming and use flexibility of having an emulated peripheral be a software object was unobtainable. For example, once a system with instruction processor (emulated or otherwise) was set up having associated emulated memory, and emulated input output (I/O) processor, the number of peripherals, or processors for that matter was set. With an object oriented design, once the class is determined, new instances of the software object subsystems (tape drives, disk drives, et cetera) can be created and used without having to redesign or reconfigure the system. Further, no external resources were available to the prior design system by Unisys. In the object design, this limitation will not exist.
Another important feature of a tape (or other legacy peripheral) emulator would be to allow the user to transfer tape files from remote systems to a Windows workstation without having a tape drive on the workstation, and having the ability to transfer the files back to the remote system (for example a legacy Unisys 2200 computer system with a CUSC70 tape drive) would also be valuable. Because the emulator would be built to use the Windows I/O to access files the emulator would be able to read from any standard Windows compatible peripheral device, including the ubiquitous CD-ROM, DVD or any other device with a Windows driver. The old emulator designs for Unisys legacy systems (a full systems emulation software suite called FLIT) were limited in use to reading from 2200 peripheral devices. One example would be the Windows operating system and accessory software file location features could be taken advantage of by software running an emulator in accord with this invention to find files in any peripheral to be used by the emulator. Further, other programs can communicate with the inventive emulator using the standard object oriented interfaces. These interfaces are commonly called object properties, methods, and events. Obviously these adaptabilities were not available when using a tape emulator as part of a 2200 system emulation.
Accordingly, if a tape drive emulator were developed as a software object, these limitations would be ameliorated and the transition from legacy systems to modern systems could be made more practical and efficient.
In an object oriented programming (OOP) environment, the software system within a computer system facilitates the actions of the instances of objects within it. The environment also allows for the programmer creation of classes of objects from which programs or users can create object instances. Programs can operate outside of the OOP environment and the OOP environment can receive and send messages to such outside programs in order to facilitate use by such outside program entities of the instances within the OOP environment. The outside program entity would need to know the name or other addressable feature of the object instance, and the object instance would be able to respond only if the OOP or the instance itself could address the outside program entity. Entities within the OOP environment also, of course, can pass messages between themselves as facilitated by the OOP environment. Addressing is typically done by sending a message bearing the name of the entity being contacted and the name (or other addressing link feature) of the sending entity can be in the message or kept track of by the OOP environment. Thus reply messages can be easily returned to the sending objects or outside program entities. The messages themselves can carry instructions or changes to properties of the object instance being addressed, or can even call for the destruction of the object instance. Objects, outside entities, programmers and users can all create object instances using predefined classes, and programmers, outside program entities, object instances can create and modify existing object classes.
Of particular use in the instant invention is the ability of the OOP environment to allow assignment of data files to object instances, wherein the object instance has some control over the data in such a file. Of course, the data file would be considered either a subsidiary object to the inventive emulator instance or, if more than one data file is loaded, a group of objects . In the preferred embodiment, a file object can get locked to the emulator instance by the user using a browse window, like the one used in Microsoft Word""s(A trademark of Microsoft Corporation) FILE/OPEN command. A browse window is an existing Microsoft object that is created by the MENU/FILE/OPEN command sequence. (In non-Microsoft systems one can employ similar devices to open similar objects to such browse windows to accomplish the same result). Using this browse window object the user can scan through the available library of data file objects identified to the browse window. Once the user finds the file he wants (which in the preferred embodiment will be in the Tape File format), the user then selects it. By this selection activity, the data file subsidiary object (a particular tape reel equivalent) is xe2x80x9cloadedxe2x80x9d or locked to the emulator object instance, and the data may be read from or written to this tape file through the emulator object instance. In the tape drive world, the loading and unloading of tape files was an operator activity, thus in the preferred embodiment it will be accomplished by a user through the browse window, although there is no reason, that where this task needs to be automated, a program could not also perform this selection and/or loading/unloading function.
These efficiencies of data management to allow simple locking of what may have been previously unavailable tape reel data files to existing emulator instances were not previously available to users of storage device emulators. In prior art emulator systems the tape file had to be loaded with the emulator software. Thus the flexibility of applying OOP environmental features to data storage device emulation becomes a valuable feature of the invention.
OOP environment operative facility is well known to people with experience in OOP, and these features are advantageously used as described herein to overcome the problems and recognize the values just outlined above. The invention is not limited to any particular OOP environment, but Visual Basic was used to develop the preferred embodiment.